「需求變更」是在執行專案時的一大難題....

「需求變更」是在執行專案時的一大難題....

以前有去上過PMP的系統課程，針對「變更管理」總是花一大章節說明如果因應變更，如何控管.....（最好就是不要變...）

但實際在執行專案時，客戶哪有可能不變更呢？

每個人每天想法都不一樣，要求不要變，哪有可能....

所以在之前，總是每次都在感測跟求上天保佑....不要變不要變，但總是「事與願違」...

因此在老師說到「歡迎變更」概念時，我心裡真是充滿了驚訝...(怎麼會有理論這麼了解實際狀況！！！)

引述老師的說法：

「敏捷開發是一種以價值為導向的方式，以人為核心，非常歡迎變更，也更加要求快速的提供專案產出，以最小能達成客戶需求的漸增開發模式，持續追求優越的技術與優良的設計，逐步完善軟體功能開發，能更加快速的達成客戶需求期望的價值，取得雙方合作共識更有效率的完成開發。」

在老師實際帶領我們運作時，因此週期很短，透過客戶訂的功能優先順序，以實際的成果進行討論。

討論的過程中，客戶看到實際的東西，就會說出真正的需求，在時間壓力不大的情況下，這種適時的變更顯得不是那麼嚴重。

也不會在最後，被迫在「客戶」與「內部壓力」二者之間為難....

最後以十二項敏捷原則為結論：

我們最優先的任務，是透過及早並持績地交付有價值的軟體來滿足客戶需求。
竭誠歡迎改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，以維護客戶的競爭優勢。
經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。
業務人員與開發者必須在專案全程中一起工作。
以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工作。
面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
可用的軟體是最主要的進度量測方法。
敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的步調。
持續追求優越的技術與優良的設計，以強化敏捷性。
精簡或最大化未完成工作量之技藝是不可或缺的。
最佳的架構、需求與設計皆來自於能自我組織的團隊。
團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為。